Users of computing devices (e.g., laptops, cellular phones, and personal digital assistants) often need to communicate in real time. A common form of real-time communications is provided by instant messaging services. An instant messaging service allows participants at endpoints to send messages and have them received within a second or two by the other participants in a conversation. The receiving participants can then send responsive messages to the other participants in a similar manner. To be effective, a real-time conversation relies on the participants' becoming aware of, reviewing, and responding to received messages very quickly. This quick response is in contrast to conventional electronic mail systems in which the recipients of electronic mail messages respond to messages at their convenience.
When an initiating participant wants to start a real-time conversation, that participant needs to know whether the intended participants are available to respond in real time to a message. If not, then communications via conventional electronic mail, voice mail, or some other mechanism may be more appropriate. For example, if the computers of the intended participants are currently powered off, then a real-time conversation may not be possible. Moreover, if their computers are currently powered on, but the intended participants are away from their computers, a real-time conversation is also not possible. The initiating participant would like to know the availability of the intended participants so that an appropriate decision on the form of communication can be made.
Presence services provide this availability information. The availability status of an entity such as a computer system (i.e., endpoint) or a user associated with that computer system is referred to as “presence information.” Presence information identifies the current “presence state” of the user. Users make their presence information available to a presence service so that other users can decide how best to communicate with them. For example, the presence information may indicate whether a user is logged on (“online”) with an instant messaging server or is logged off (“offline”). Presence information may also provide more detailed information about the availability of the user. For example, even though a user is online, that user may be away from their computer in a meeting. In such a case, the presence state may indicate “online” and “in a meeting.”
In an instant messaging context, a publishing user (“publisher”) may provide their presence information to a presence server that then provides the presence information to subscribing users (“subscribers”). Thus, a presence server may use a subscriber/publisher model to provide the presence information for the users of the presence service. Whenever the presence information of a user changes, the presence server is notified of the change by that user's computer system and in turn notifies the subscribing users of the change. A subscribing user can then decide whether to initiate an instant messaging conversation based on the presence information of the intended participants. For example, if the presence information indicates that a publishing user is currently in a conference telephone call, then the subscribing user may decide to send an instant message, rather than place a telephone call, to the publishing user. If the subscribing user, however, needs to call and speak with the publishing user, the subscribing user needs to monitor the presence information of the publishing user to know when the call can be placed. When the subscribing user notices that the publishing user's presence information indicates that the telephone conference has been concluded, the subscribing user can then place the telephone call. A specification relating to presence information in instant messaging systems, “RFC 2778.” A draft of a proposed specification relating to presence information using the Session Initiation Protocol (“SIP”) is available at “internet-drafts/draft-ietf-simple-presence-10.txt”of the Internet Engineering Taskforce website.
To support real-time communications, communications applications typically need to establish and manage connections (also referred to as sessions or dialogs) between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications such as MESSENGER or VoIP establish sessions between communicating devices on behalf of users. These applications may use various mechanisms to establish sessions, such as the Session Initiation Protocol (“SIP”). SIP is an application-level control protocol that computing devices can use to discover one another and to establish, modify, and terminate sessions between computing devices. SIP is a proposed Internet standard. The SIP specification, “RFC 3261,” is available at “rfc/rfc3261.txt” of the Internet Engineering Taskeforce website.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate dialogs by exchanging messages with other SIP entities. A user agent can be a user agent client (“UAC”), which is a device that initiates SIP requests, or a user agent server (“UAS”), which is a device that receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a UAC in one dialog and a UAS in another, or may change roles during the dialog. A proxy server is a device that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between UACs and UASs. A redirect server is a device that accepts a SIP request and generates a response directing the UAC that sent the request to contact an alternate network resource. A registrar is a server that accepts registration information from user agents and informs a location service of the received registration information.
SIP supports two message types: requests, which are sent from a UAC to a UAS, and responses, which are sent from a UAS to a UAC when responding to a request. A SIP message is composed of three parts. The first part of a SIP message is a “request line,” which includes fields to indicate a message method (e.g., INVITE) and a Request URI that identifies the user or service to which the request is being directed. The second part of a SIP message comprises headers whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data that relates to the session. Message bodies may appear in requests or responses.
User agents can communicate by sending SIP messages during a SIP dialog. A SIP dialog is a peer-to-peer relationship between two user agents that persists for some time. A dialog may be established when a UAC sends an INVITE request to a UAS and the UAS replies with a 200 OK response.
SIP is often used as the protocol for communicating with a presence server. Each publisher and subscriber uses SIP to establish a dialog with the presence server and to subscribe to and publish presence information. When the presence information of a publisher is updated, the presence server sends a SIP NOTIFY message to each subscriber. The message identifies the publisher and includes the updated presence information of the publisher.
Because of the popularity of instant messaging and other real-time services, a provider of presence services often needs to provide a pool of servers to support the presence service. For example, a large organization may need to provide presence information for tens of thousands of users. Because of the real-time requirements and the high volume of communications that are sent between the clients and servers of a presence service, a single server is typically not sufficient. Although the presence service may be provided by a pool of presence servers, the pool appears as a single presence server to the client. For example, when a client logs on to or establishes a connection with a presence service, the logon request may be routed through a load balancer that selects an available server of the server pool and directs the logon request to the selected server. When a client publishes presence information of its user, the client's server provides the presence information to the client's subscribers. The information of the presence service may be stored and accessed through a back-end database server, which may be a SQL server. The back-end database server may store the current presence information of each publisher, and for each publisher, store the identity of each subscriber to that publisher's presence information in database tables. When a front-end presence server receives a request, it accesses the back-end database server to respond to the request.
Some implementations of SIP require that all messages of a session travel through the same sequence of devices (e.g., proxy servers). Thus, when the load balancer of a server pool assigns an available server through which a client is to log on, all subsequent messages of the session from the server pool to the client need to include that assigned server. The presence server tracks such “home” server for each client by storing a mapping of client to home server in the back-end database.
When the presence servers receives a request from a publisher to update the publisher's presence information, the home server for the publisher is responsible for updating the publisher's presence information in the back-end database and for initiating the sending of notifications to the subscribers of the publisher's presence information. The home server of the publisher typically identifies the subscribers and uses the mapping of client to home server to identify the home server of each client. The home server of the publisher then sends, for each subscriber, a SIP NOTIFY message to the subscriber's home server. Upon receiving the SIP NOTIFY message, the subscriber's home server then sends a SIP NOTIFY message to the subscriber's computing device. This allows a SIP NOTIFY message that is received at a subscriber to have originated from the home server of the subscriber as required by some implementations of SIP.
Unfortunately, the establishing of SIP dialogs and sending of SIP messages between servers can have a high overhead. This high overhead adversely affects both the response time of a pool of servers and the number of publishers and subscribers that a pool of servers can support.